home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000007_icon-group-sender_Fri Aug 16 16:13:56 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNDrE22997
  4.     for icon-group-addresses; Fri, 16 Aug 2002 16:13:54 -0700 (MST)
  5. Message-Id: <200208162313.g7GNDrE22997@baskerville.CS.Arizona.EDU>
  6. From: jenjhiz@yahoo.com (Gene Kahn)
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: What about "Expressions?" (was Re: Icon Wish List)
  9. Date: 16 Aug 2002 08:38:22 -0700
  10. X-Complaints-To: groups-abuse@google.com
  11. To: icon-group@cs.arizona.edu
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13. Status: RO
  14.  
  15. Hrvoje Blazevic <hrvoje@despammed.com> wrote in message news:<pan.2002.08.15.23.16.43.204175.3145@despammed.com>...
  16. > On Thu, 15 Aug 2002 18:53:13 +0200, Christopher Browne wrote:
  17. [snip]
  18. > 
  19. > Imperative languages use statements -- which results in flow of
  20. > information between different parts of program being passed in the
  21. > form of a variable assignment.
  22. > 
  23. > Statements do not return values, they have side-effects, most notably
  24. > assignment to variables that describe the state of the computation at
  25. > any given moment.
  26. > 
  27. This is not without its advantage, of course. In particular, in terms
  28. of readability, I find that explicit variables allow my mind to
  29. 'close' (I'm not using it in the technical sense of "closure")
  30. previous statements. On the other hand, in reading s-expression
  31. languages like Lisp and Scheme, I find that I have to hold in my mind
  32. too many _unstated_ intermediate results before I find what the
  33. expression is all about. (One could argue that this may be due more to
  34. bad code, i.e., irresponsible use of deep embedding, than to intrinsic
  35. properties of s-expressions). Compare the readability of these chunks
  36. of code:
  37.  
  38. FORTRAN-like
  39. The man kicked the dog.
  40. The dog chased the cat.
  41. The cat bit the mouse.
  42. The mouse died. 
  43.  
  44. LISP-like (in infix notation)
  45. The mouse the cat the dog the man kicked chased bit died.
  46.  
  47. Of course, variable-less, assignment-less languages have advantages. 
  48.  
  49. Speaking of speaking (or writing) grammatical English, which skill has
  50. been implied in a recent post as a 'requisite' for programming, what
  51. do readers with good English grammar think of this sentence:
  52. grammatically correct or not? Be careful with your answer. Your
  53. reputation as a programmer is on the line.
  54.  
  55. The horse raced past the barn collapsed. 
  56.  
  57.  
  58. > Although Icon *is* imperative language it can get away with less state
  59. > variables than most, simply because it uses expressions which return
  60. > values. Therefore smaller chunks of code in Icon do not have to
  61. > describe state as the set of variables.
  62. > 
  63. > I may be getting over my head here, because I'm *not* an Icon
  64. > programmer. I did get briefly involved with Icon about 10 years ago,
  65. > just after several years of down and dirty imperative programming
  66. > using Pascal and C/C++. At that time I read "The Icon Programming
  67. > Language" (2nd edition), and was instantly drawn to Icon. 
  68. > Unfortunately at about the same time my son reached fourth
  69. > grade, and I wanted to start him on a road to CS, so I started looking
  70. > at Logo.
  71. > 
  72. > After that, the road was clear; Logo, Lisp (emacs lisp), Scheme and Haskell.
  73. > 
  74. > I do not think that I'll ever go back to Icon, but I still sometimes
  75. > check the web site, nostalgia ... probably :-)
  76.